Transcript Document
Interoperability in eHealth Systems
Asuman Dogac, SRDC Ltd.
August 30, 2012 1
It was many and many a year ago…
There were standalone computers…
Then came the networks and the Internet…
Then it became apparent that there would be huge benefits to be gained if the applications can talk to one another…
Email is one such application although it is mostly for human consumption…
August 30, 2012 VLDB 2012 2
What if…
What if Electronic Health Records are widely used and shared?
9 million bed-days could yearly be freed up corresponding to a value of €3,7 billion What if Computerised Physician Order Entry are widely used?
100,000 adverse drug events could be avoided yearly What if ePrescriptions are widely used?
5 million prescription errors could be avoided yearly What if Chronic Disease Management patients?
is used for diabetes 11,000 diabetic deaths could be avoided every year Ref: a recent study covering 6 EU countries by realizing eHealth (epSOS) To achieve this, you need all the systems working together seamlessly: interoperability is needed August 30, 2012 VLDB 2012 3
Outline
Major Interoperability Standards and Profiles in eHealth Interoperability Stack Communication and Transport Layer Document/Message Layer Business Process Layer Profiling Semantic Interoperability in eHealth Clinical Terminology Systems Medical Device Standards Real Life Uses Sharing Electronic Health Records Saglik-Net in Turkey and epSOS in Europe Monitoring Chronic Diseases Patients with Cardiac Implants and Diabetes patients Secondary use of EHRs in Clinical Research August 30, 2012 VLDB 2012 4
Two points…
The talk is divided into two main parts:
Description of some of the interoperability standards (which may not be very thrilling ) Description of some real life uses seems more interesting
It is not “all applied work”; it includes research
5 August 30, 2012 VLDB 2012
Interoperability (Def ’n)
Interoperability with regard to a specific task is said to exist between two applications when one application can accept data (including data in the form of a service request) from the other and perform the task in an appropriate and satisfactory manner (as judged by the user of the receiving system) without the need for extra operator intervention Ref: Brown, N. and Reynolds, M. 2000. Strategy for production and maintenance of standards for interoperability within and between service departments and other healthcare domains. Short Strategic Study CEN/TC 251/N00-047, CEN/TC 251 Health Informatics, Brussels, Belgium.
This definition implies the following: The ability to communicate data (connectivity) The data received by the receiving system is sufficient to perform the task and The meaning attached to each data item is the same as that understood by the creators and users of the sending and receiving systems The task is performed to the satisfaction of the user of the receiving system August 30, 2012 VLDB 2012 6
Interoperability and Standards
Interoperability is possible by conforming to standards
Otherwise an application wishing to communicate with n different applications must develop that many different interfaces
August 30, 2012 VLDB 2012 7
The nice thing about standards is that there are so many to choose from
!
August 30, 2012 VLDB 2012 8
Some of the Main Standard Bodies in eHealth
HL7 (Health Level Seven) Founded in 1987 A non-profit, ANSI accredited Standards Developing Organization Provides standards for the exchange, management, and integration of data that supports clinical patient care and the management, delivery, and evaluation of healthcare services Integrating the Healthcare Enterprise (IHE) Founded in 1998 in the USA by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS) A not-for-profit initiative The goal is to stimulate integration of healthcare information resources CEN/TC 251 The technical committee on Health Informatics of the European Committee for Standardization Its mission is to achieve compatibility and interoperability between independent health systems August 30, 2012 VLDB 2012 9
Messages vs. Documents in Healthcare IT
Messages They support an ongoing process in a real-time fashion They drive activities and may trigger further events They use the latest version of the data to support an ongoing process They are consumed to realize that event Documents They have “static” content and have to be persisted They tend to be used “post occurrence”, i.e. once the actual process is done They are "passive“ They capture information and allow that information to be shared, but do not themselves drive any activity They are self contained such as an Electronic Health Record (EHR) EHRs are documents also for medico-legal reasons: a medical professional takes the responsibility for the information contained in it August 30, 2012 VLDB 2012 10
HL7 Message Standards
The HL7 standard is developed with the assumption that an event in the healthcare world, called the
trigger event
, causes the exchange of messages between a pair of applications When an event occurs in an HL7-compliant system: An HL7 message is prepared by collecting the necessary data from the underlying application systems and It is passed to the requestor, usually as an EDI (Electronic Data Interchange) message For example, a trigger event, called ADT^A01 (admission/ discharge/ transfer —admission of an inpatient into a facility), occurs when a patient is admitted to a facility This event may cause the data about the patient to be collected and sent to a number of other application systems Currently, there are two message protocols supported by HL7, Version 2 and Version 3 August 30, 2012 VLDB 2012 11
HL7 Message Standards
HL7 Version 2 Messaging Standard is the most widely implemented standard for healthcare information in the world today However, Version 2 messages have no precisely defined underlying information model; The definitions for many data fields are rather vague, and There are a multitude of optional data fields Being HL7 Version 2-compliant does not imply direct interoperability between healthcare systems This optionality provides great flexibility but necessitates detailed bilateral agreements among the healthcare systems to achieve interoperability To remedy this problem, HL7 developed Version 3 which is based on an object-oriented data model called Reference Information Model (RIM) Up to the current Version 2.5, the scope of the HL7 standard was limited to the exchange of messages between medical information systems Starting with Version 3.0, a document markup standard, called the Clinical Document Architecture (CDA), is proposed August 30, 2012 VLDB 2012 12
Exchanging HL7 messages…
Interface Engine HL7-I12 Patient Referral ^ HL7-I12 Patient Referral 12345 john ^ smith Interface Engine 12345 smith john Application 1: HIS Database and back
11011010 Network (e.g., VAN) VLDB 2012
Application 2: HIS Database and back end applications
13
Interoperability Stack
August 30, 2012 14
Interoperability Stack…
Interoperability involves not a single standard but a collection of standards addressing different layers in the interoperability stack There are several alternative standards to be chosen from for each layer Some standards specify a range of standards for a layer E.g., HL7 v3 provides a number of normative specifications for the transport layer such as ebMS or Web services Profiling avoids this problem by fixing the combination of the standards and even further restricting them to provide interoperability Integrated Healtcare Enterprises (IHE) HITSP in USA for NHIN Ministry of Health, Turkey for NHIS
15
August 30, 2012 VLDB 2012 15
Interoperability Stack
August 30, 2012 Document Layer Business Process Layer Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, EHRCom, ... Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging) Terminologies/Coding Systems: LOINC, SNOMED, ...
Business Rules (e.g by using schematrons) Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams) Choreography/Business Process Standards: WSCDL, ebBP Communication Layer
Quality of Service Protocols:
WS-Reliability, WS-Security, WS-Addresing Higher Level Messaging Protocols: SOAP, ebMS, ... Transport Protocols: HTTP, SMTP, MLLP, ...
16
VLDB 2012 16
Health Level 7 (HL7) Message Standards
HL7 v2.x
At the document layer, it defines the contents of messages with a lot of optional fields which provides flexibility but reduces interoperability It recommends several protocol alternatives for the communication layer such as “Minimal Lower Layer Protocol (MLLP)” based on TCP/IP HL7 v3 Defines a generic structure to express the concepts in a domain, called “Reference Information Model (RIM)” This generic RIM is then refined to subdomains and later to specific domain concepts For example, the HL7 RIM can be specialized into: “ CDA ” for expressing clinical documents , “Clinical genomics” for expressing clinical and personalized genomics data , and “Claims and reimbursement” for handling claims and reimbursements It recommends several protocol alternatives for the communication layer ebXML Message Specification Profile Web Services Profile TCP/IP based Minimal Lower Layer Protocol Profile There are interactions
sequence diagrams
to describe the choreography of the August 30, 2012 VLDB 2012 17
Some Document Standards…
HL7 v3 Clinical Document Architecture (CDA) Defines the structure and semantics of medical documents for the purpose of exchange in Extensible Markup Language (XML) openEHR First, a generic reference model that is specific to the healthcare domain which contains a few classes (e.g., role, act, entity, participation) Then healthcare and application-specific concepts such as blood pressure, lab results are modeled as archetypes, that is, constraint rules that specialize the generic data structures ISO/CEN 13606-1 Has a reference model and uses openEHR archetypes to constrain them ASTM Continuity of Care Record (CCR) Defines a core data set for the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more healthcare encounters Contains various sections such as patient demographics, insurance information, diagnosis and problem list, medications, allergies and care plan
All these standards, except CCR, define quite generic structures such as folder, section, entry that can be used to represent any kind of clinical statement
August 30, 2012 VLDB 2012 18
Content Templates..
Document standards are not enough for interoperability because there can be many different ways of organizing the same clinical information even when the same EHR content standard is used: The same information can be expressed through different components and these components can be nested differently Therefore, the templates/archetypes are necessary to constrain the structure and format of generic EHR content standards For example, IHE defines several content templates such as Discharge Summary, Medical Summary or PHR Extract As another example, Continuity of Care Document (CCD) is defined by constraining HL7 Clinical Document Architecture (CDA) with requirements set forward in CCR However, overlapping coding systems as well as the structural differences in document templates create semantic interoperability problems : Different code systems used by different healthcare applications in the same compositional structure within the same document template; Different compositional structures within the same document template that express the same meaning differently August 30, 2012 VLDB 2012 19
An Example to Interoperability Problems of Content Templates
August 30, 2012 VLDB 2012 20
Interoperability Stack
Document Layer Business Process Layer Communication Layer Industry Specific XML Schemas: HL7 v3 Messages, HL7 CDA, EHRCom, ...
Integration Profiles
(e.g. IHE in eHealth or NES UBL in eBusiness) Non-XML Content: HL7 v2 Messages (EDI), X12, DICOM (Medical Imaging) Terminologies/Coding Systems: LOINC, SNOMED, ...
Business Rules (e.g by using schematrons) or Specifications with Diagrams: e.g. IHE(Actor/Transaction Diagrams,Sequence Diagrams) , HL7 (Sequence Diagrams) Choreography/Business Process Standards: WSCDL, ebBP Higher Level Messaging Protocols: SOAP, ebMS, ... Transport Protocols: HTTP, SMTP, MLLP, ...
Technical Specification s
(National or Regional Health
Quality of Service Protocols:
WS-Reliability, WS-Security, WS-Addresing Networks: e.g. USA NHIN, NICTIZ, Saglik NET)
21
August 30, 2012 VLDB 2012 21
Semantic Interoperability in eHealth
August 30, 2012 22
Semantic Interoperability in eHealth
Ability for information shared by systems to be understood through formally defined domain concepts In medicine, the clinical information is coded with “controlled vocabularies” or “terminologies” to express semantics, i.e., the meaning of the terms used For example, the observation for a patient can be expressed as a “heart attack” or a “myocardial infarction”, and these mean the same thing to medical professionals But unless the term is associated with a unique code from a code system, automated processing of the exchanged term is very difficult because an application, programmed to use “heart attack”, would not understand “myocardial infarction” When a term from medical terminology system is used such as SNOMED CT and the code 22298006 for “Myocardial infarction”, the automated meaning exchange is possible Different coding systems used by data exchanging applications causes semantic interoperability problems August 30, 2012 VLDB 2012 23
Classification of Terminology Systems
The terminology systems can be classified based on how they express the semantics of the relationships between the coded terms:
Some are plain code lists, for example RxNorm Some are organized into a hierarchy, for example ICD-10 and hence give the parent-child information among the terms; Some express the relationships between the coded terms through ontological constructs, for example SNOMED CT or semantic networks like Unified Medical Language System (UMLS) August 30, 2012 VLDB 2012 24
SNOMED CT (Systematized Nomenclature of Medicine -- Clinical Terms)
SNOMED CT (http://www.ihtsdo.org/snomed-ct/) is a computer processable collection of medical terminology covering most areas of clinical information such as Diseases, Findings, Procedures, Microorganisms, and Pharmaceuticals It is the most comprehensive clinical vocabulary It is developed in native description logics (DL) formalism It contains approximately 350,000 active concepts, more than one million terms (incl. synonyms) and about 1.5 million relations between the concepts SNOMED CT crossmaps to other terminologies such as ICD-10 and LOINC as well August 30, 2012 VLDB 2012 25
Terminology Mappings
Terminology mappings are needed for semantic interoperability in eHealth Currently, several sources provide terminology system mappings UMLS (http://www.nlm.nih.gov/research/umls/) contains more than 60 families of biomedical vocabularies together with context and inter-context relationships among them BioPortal (
http://bioportal.bioontology.org/)
, contains ontological representations of more than 290 terminology systems and their mappings August 30, 2012 VLDB 2012 26
The Unified Medical Language System (UMLS)
It is a compendium of many controlled vocabularies Provides a mapping structure among these vocabularies and thus allows one to translate among the various terminology systems UMLS Building Blocks Knowledge Sources Metathesaurus Defines concepts and mappings to source vocabularies It links alternative names and views of the same concept and identifies useful relationships between different concepts Semantic Network A consistent categorization of all concepts represented in the Metathesaurus and provides a set of useful relationships between these concepts For example, Addison’s Disease’s Semantic Type is “Disease or Syndrome”, and there is a “causes” relationship between “Virus” and “Disease or Syndrome” Semantic Types Knowledge Source Server Internet access to knowledge sources by browser or web service API August 30, 2012 VLDB 2012 27
Metathesaurus Sources
The Metathesaurus comprises over 1 million biomedical concepts and 5 million concept names, all of which stem from the over 100 incorporated controlled vocabularies and classification systems Built from electronic versions of many different controlled vocabularies Thesauri, e.g., MeSH Statistical Classifications, Billing Codes, e.g., ICD-9, ICD-10, ICPC e.g., CPT, CPT Spanish version, HCPCS Clinical Coding Systems, Nursing Vocabularies, e.g., SNOMED, Read e.g., NIC, NOC, OMAHA Alternative/Complementary Medicine: ALTLINK Drug Sources: Multum, Micromedex, VANDF Drug Regulatory, e.g., MedDRA Lists of controlled terms, e.g., COSTAR, HL7 Arden Syntax August 30, 2012 VLDB 2012 28
An Example: Terms in the UMLS for “Addison’s disease” Concept CUI C0001403
Term Name
Addison’s disease Addison’s Disease Addison Disease Bronzed disease Primary Adrenal Insufficiency Primary hypoadrenalism syndrome, Addison August 30, 2012
Source Vocabulary
SNOMED CT MedlinePlus MeSH SNOMED Intl MeSH MedDRA VLDB 2012
Code in the Source Vocabulary
363732003 T1233 D000224 DB-70620 D000224 10036696 29
A part of UMLS Semantic Network
August 30, 2012 VLDB 2012 30
Interoperability of Terminology Systems
To achieve interoperability among terminology systems
Not only the mapping information between them But also the semantic relationships among the terms (or, concepts) in a terminology system are necessary Because this helps discovering the implicit equivalences between two terms from different terminology systems by using reasoning However, the automated mappings cannot be fully reliable Therefore, continuous involvement of terminology experts and health care professionals in this process is necessary August 30, 2012 VLDB 2012 31
An Example
Assume a patient’s acute heart failure condition is expressed with SNOMED CT code 56675007 in a clinical document Receiving application understands only the MedDRA terminology system Through reasoning, it is possible to discover that the equivalent MedDRA code is 10019279 for “heart failure” subclass SNOMED CT Heart Failure 84114007 SNOMED CT Acute heart failure 56675007 Equivalent class MEDRA Heart Failure 10019279 August 30, 2012 VLDB 2012 32
Semantic Mediation
!
August 30, 2012 VLDB 2012 33
An Example to How Some of the Mentioned eHealth Standards Used in Practice Sa ğlık-Net: The National Health Information System (NHIS), Turkey
August 30, 2012 34
National Health Information System of Turkey (NHIS-T)
National Health Information System of Turkey (NHIS-T) is a nation wide infrastructure for sharing patients’ electronic health records (EHRs) The NHIS-T became operational on January 15, 2009 By Feb. 2012, 98% of the public hospitals and 60% of the private and university hospitals were connected to NHIS-T with daily feeds of their patients’ EHRs Out of 74 million citizens of Turkey, electronic healthcare records of 60 million citizens have already been created in NHIS-T As of Feb. 2012, there are 661 million EHRs in the system ~ 427 million Observation records ~ 110 million Mouth and Teeth examination records ~ 21 million In-patient records August 30, 2012 VLDB 2012 35
Collecting EHRs
NHIS, Turkey Public Hospitals
August 30, 2012
General Practitioner (Family Medicine Information System
VLDB 2012
Private Hospitals University Hospitals
36
The National Health Data Dictionary (NHDD)
The National Health Data Dictionary (NHDD) is developed to enable the parties to share the same meaning of data 46 Minimum Health Data Sets (MHDS) and 261 data elements
Some data elements
Address Name Main Diagnosis Vaccination Treatment Method Diastolic Blood Pressure Healthcare Institution Marital Status August 30, 2012 VLDB 2012
Some MHDSs
Citizen/Foreigner Registration MHDS Medical Examination MHDS Prescription MHDS Pregnant Monitoring MHDS Cancer MHDS Inpatient MHDS 37
August 30, 2012 VLDB 2012 38
An Example Transmission Schema (“Examination”)
August 30, 2012 VLDB 2012 39
NHIS, Turkey Overview
Content Layer
HL7 CDA is used as the EHR content format CDA sections correspond to Minimum Health Data Sets (MHDSs) The MHDSs use the data elements from the National Health Data Dictionary (NHDD) Turkish Citizen Numbers are used as patient identifiers
Communication Layer
HL7 Web services Profile with WS-Security over SSL August 30, 2012 VLDB 2012 40
NHIS “Transmission Schemas”
Healthcare Professional Identifiers: Checked from the Doctor Data Bank http://sbu2.saglik.gov.tr/drBilgi/ Patient Identifiers: Citizen numbers are used and checked from the MERNIS database Codes used: Checked from the National Health Coding Reference Server http://ky.sagliknet.saglik.gov.tr/SKRS2_Listesi Security and Privacy: Various view mechanisms to hide the patient demographics information Business rules: Checked with Schematron rules August 30, 2012 VLDB 2012 41
Healthcare Professional Registry
Ministry of Health is authorized to provide the work licenses to the physicians in Turkey The diploma/specialty information of the medical professionals is recorded together with their Turkish citizenship numbers in the Doctor Data Bank (DDB) As of October 2007, there are 162,446 registered doctors in the data bank The Doctor Data Bank is for checking the validity of the healthcare professional identity in the “Transmission Schema” Later it will be used authorizing access to the EHRs of the patients August 30, 2012 VLDB 2012 42
25 HL7 Web Services for Transporting EHRs
“15–49 Age Female Observation” “Mouth and Teeth Examination” “Vaccine Notification” “Infant Nutrition” “Infant Observation” “Infant Psychosocial Observation” “Communicable Disease Definite Case Notification” “Communicable Disease Probable Case Notification” “Diabetes” “Dialysis Notification” “Dialysis Observation” “Birth Notification” Pregnant Observation” “Pregnancy Termination” “Pregnant Psychosocial Observation” “Patient Demographics Notification” “Cancer” “Puerperal Observation” “Examination” “Death Notification” “Test Result” “Citizen/Foreigner Registration” “Stateless Person Registration” “Newborn Registration” and “Inpatient” August 30, 2012 VLDB 2012 43
Validation of the Messages by the NHIS
Valid Codes from National Code Valid SOAP message?
Valid use of WS-Security User Name Token Profile?
should be less than the system time.)
12345 Yılmaz Ahmet HIS of Hospital A
11011010 Internet August 30, 2012 Observation Service VLDB 2012
NHIS
44
Handling Security and Privacy
There are two types of administrators in the system: Security Administrator is in charge of granting rights to the Database Administrators but they themselves have no right to access the database Various “View” mechanisms are developed to hide the patient demographics data from the unauthorized users The MoH has selected Oracle Identity Management System Access to NHIS data is audited by logging all the user events Currently the work is going on for determining the legal ground about the access rights of various types of users August 30, 2012 VLDB 2012 45
Decision Support System
Child mortality rate under the age of 12 months in Bilecik?
Number of diarrhea incidents in Istanbul during the last three days?
Number of cancer incidents during last year in all of the provinces of Turkey?
Decision Support System NHIS
August 30, 2012 VLDB 2012 46
Note..
In Turkey, although the EHRs are collected, they are shared only with General Practitioners but not with the physicians in the secondary and tertiary care This is because there is a need for a consent mechanism for the patients The next step is to allow sharing of EHRs not only with authorized medical practitioners but also with the patients themselves
Through a Personal Health Record system, called, eSaglikKaydim August 30, 2012 VLDB 2012 47
Personal Health Record Systems
The Personal Health Record (PHR) systems have evolved from Web pages where patients entered their own data manually Currently, they are classified as: Provider-tethered PHR system automatically : Data from a medical provider’s healthcare information system is entered into the PHRs Payer-tethered PHR systems provide patients access to claims data Third party PHR systems such as Microsoft HealthVault that provides a secure storage for PHR data together with data exchange interfaces so that third parties can develop applications to upload patient data, for example, home health devices Interoperable PHR systems , on the other hand, represent a future type of PHR in which all entities have access to data A recent report by Google, HIMSS, Kaiser Permanente and Microsoft concludes that from the perspective of the healthcare system, interoperable PHRs provide the greatest value August 30, 2012 VLDB 2012 48
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
August 30, 2012 VLDB 2012
Factors Affecting the Success of NHIS, Turkey
The Ministry of Health, being the national authority to decide on the eHealth standards in Turkey, was able to enforce the standards that have led to their fast adoption Building a national common data dictionary consisting of eHealth data elements and minimum health data sets has helped to Identify clearly the meaning of data elements; Giving their explanation in the local language and, more importantly, Making it possible to share and re-use these components Finally, the comprehensive testing, especially the conformance and interoperability testing of vendor-based hospital information systems contributed to the fast integration of the majority of the 65 HIS vendors in Turkey Note however that while addressing the national level EHR interoperability may be relatively easy, it is much more difficult to do this in an international environment August 30, 2012 VLDB 2012 58
Related Publications
Although this is applied work, it also involved research: Asuman Dogac, Mustafa Yuksel, et. al.,”Electronic Health Record Interoperability as Realized in Turkey’s National Health Information System”,
Methods of Information in Medicine
, Vol. 50, No. 2, March 2011, pp. 140 –149. Namli, T., Dogac, A., “Testing Conformance and Interoperability of eHealth Applications”,
Methods of Information in Medicine
, Vol. 49, No.3, May 2010, pp. 281 –289. Namli T., Aluc G., Dogac A., “An Interoperability Test Framework for HL7 based Systems”,
IEEE Transactions on Information Technology in Biomedicine
Vol.13, No.3, May 2009, pp. 389-399. Namli T., et. al., “Testing the Conformance and Interoperability of NHIS to Turkey’s HL7 Profile”, 9th International
HL7 Interoperability Conference
(IHIC) 2008, Crete, Greece, October, 2008, pp. 63-68.
Kabak Y., Dogac A., et. al., “The Use of HL7 CDA in the National Health Information System (NHIS) of Turkey, 9th International
HL7 Interoperability Conference
(IHIC) 2008, Crete, Greece, October, 2008 pp. 49-55.
Eichelberg M., Aden T., Riesmeier J., Dogac A., Laleci G., “A Survey and Analysis of Electronic Healthcare Record Standards”,
ACM Computing Surveys
, Vol. 37, No:4, December 2005.
August 30, 2012 VLDB 2012 59
Some Other Related Publications
ARTEMIS: An Infrastructure for the Interoperability of Medical Information Systems, Healthcare IT Management Journal, Volume 1, Issue 2, Summer 2006, pp.26-27.
“Artemis: Deploying Semantically Enriched Web Services in the Healthcare Domain”, Information Systems Journal (Elsevier), Volume 31, Issues 4-5, June-July 2006, pp.321 339 Collaborative Business Process Support in IHE XDS through ebXML Business Processes, In proc. of International Conference on Data Engineering (ICDE2006) Exploiting ebXML Registry Semantic Constructs for Handling Archetype Metadata in Healthcare Informatics, International Journal of Metadata, Semantics and Ontologies, Volume 1, No. 1, 2006.
The Need for Semantic Web Service in the eHealth, W3C workshop on Frameworks for Semantics in Web Services Archetype-based Semantic Interoperability of Web Service Messages in the Healthcare Domain, Int'l Journal on Semantic Web & Information Systems, Vol. 1, No.4, October 2005, pp. 1-22.
Artemis Message Exchange Framework: Semantic Interoperability of Exchanged Messages in the Healthcare Domain, ACM Sigmod Record, Vol. 34, No. 3, September 2005 August 30, 2012 VLDB 2012 60
Some example Integrating Healthcare Enterprise (IHE) Profiles
August 30, 2012 61
IHE Retrieve Information for Display (RID)
IHE RID provides provides read-only access to patient centric clinical information that is located outside the user’s current application
Standards Used
: Web Services (WSDL for HTTP Get).
General purpose IT Presentation Formats:
XHTML, PDF, JPEG, CDA L1
Client may be off-the-shelf browser or display application.
Two services
: Retrieve of Specific Information: Patient centric: patient ID Type of Request (see next slide) Date, Time, nMostRecent Retrieve a Document Object Unique Instance Identifier (OID) Type of Request Content Type Expected August 30, 2012 VLDB 2012 62
IHE Retrieve Information for Display
August 30, 2012 •
Summary of All Reports
•
Summary of Laboratory Reports
•
Summary of Radiology Reports
•
Summary of Cardiology Reports
•
Retrieve Specific Info for Display
•
Summary of Intensive Care Reports
•
Summary of Emergency Reports
•
Summary of Discharge Reports
•
List of Allergies
•
List of Medications IHE-RID WSDL
IHE XDS – Cross Enterprise Document Sharing
XDS is IHE’s first step towards the longitudinal dimension of the EHR (“from cradle to grave”) Focus: Support document sharing between EHRs in different care settings and organizations Clinical Affinity Domains (like the RHIOs in the States) One registry (ebXML) to store the metadata of the documents One or several repositories where documents are actually stored IHE-XDS is content neutral Design Premises: Organisations that decide to share clinical documents form a group that is called a “Clinical Affinity Domain”, which has to Establish common a patient ID management scheme (MPI) Define a common set of meta data and permitted content formats Define a common set of policies Share a single metadata registry August 30, 2012 VLDB 2012 64
IHE XDS Transaction Diagram
Document Source Patient Identity Source Patient Identity Feed Document Registry Query Documents Provide&Register Document Se t Document Set Document Repository Retrieve Document Document Consumer
August 30, 2012 VLDB 2012 65
IHE XDS
Business Process Layer : There are five actors in this profile Document Source Actor submits an EHR with the “Provide and Register Document Set” transaction to the Document Repository Document Repository contains the EHRs and registers the metadata of the documents to the Document Registry with “Register Document Set” transaction Document Registry contains the metadata of the documents Patient Identity Source aligns the different Patient IDs Document Consumer queries the registry with “Query Documents” transaction with metadata to obtain the pointer to the EHR in the Document Repository Document Consumer uses the “Retrieve Document” transaction to obtain the document from the Document Repository using the pointer Document Layer : To be decided by each Clinical Affinity Domain (CDA, pdf,…) Communication Layer : ebXML Registry specification 3.0 (MTOM based Web services) August 30, 2012 VLDB 2012 66
An Example to How IHE Profiles are Used in Practice
epSOS - European Patients Smart open Services
August 30, 2012 70
Exchanging Patient Summaries and ePrescriptions in Europe: The epSOS initiative
• • • • • • Different languages Different eHealth processes Different grade of development Different Legislation Different concepts No European Nomenclature for Medicines August 30, 2012 VLDB 2012 71
The epSOS participating nations
August 30, 2012 VLDB 2012 72
The epSOS Solution
Patient Summary for European Citizens ePrescription service for European Citizens ePrescribing is the electronic prescribing of medicine using software to transmit the prescription data to the pharmacy where it is being retrieved eDispensing is the electronic retrieval of an ePrescription, the dispensing of the medicine to the patient and the submission of an electronic report for the medicine dispensed The content templates for the three document types Patient summary, ePrescription and eDispensation These pivot documents to be exchanged are defind by using and further restricting IHE PCC templates Each country defines its own mapping from its national data structures onto these pivot document schemas August 30, 2012 VLDB 2012 73
Important Standards Used in epSOS
Content models for Patient Summary, ePrescription and eDispensation documents HL7 Clinical Document Architecture – CDA v2 HL7/ASTM Continuity of Care Document (CCD) Content templates Integrating the Healthcare Enterprise (IHE) Patient Care Coordination (PCC) Content templates Clinical Terminology Systems ICD 10, SNOMED CT, LOINC, ATC, … Interoperability Profiles IHE Cross-Community Patient Discovery (XCPD) profile IHE Cross-Community Access (XCA) profile IHE Cross-Enterprise Document Reliable Interchange (XDR) profile Security IHE Cross-Enterprise User Assertion (XUA) profile IHE Audit Trail & Node Authentication (ATNA) profile … August 30, 2012 VLDB 2012 74
The epSOS Solution
For the coded representation of clinical content within these schemas, subsets from existing terminology systems are used SNOMED CT, ICD-10, LOINC, ATC, … epSOS Master Value Sets Catalogue (MVC) is created The latest version 1.7 of MVC contains 46 value sets For example, The procedures value set contains 102 terms from SNOMED CT and Illnesses and disorders value set contains 1685 terms from ICD-10 Each epSOS participating nation provides Mapping of any locally used terminology system to MVC content and also Translation of the MVC content into its own language, resulting in the epSOS Master Translation/Transcoding Catalogue (MTC) August 30, 2012 VLDB 2012 75
The epSOS Solution
Structured Document based on HL7 CDA R2 with coded entries PDF as “printable” representation of the original data
Worldwide recognized HL7 CDA templates (HL7 CCD; IHE PCC)
August 30, 2012 VLDB 2012
PDF embedded in an unstructured HL7 CDA R2 document
76
Redundant Coded Data Elements for Safety
Country A Data C-A Code C-A Display name
@
Pivot Document In Country A C-A Code C-A Display name epSOS Code epSOS English Display name
@
Pivot Document In Country B C-A Code C-A Display name epSOS Code epSOS English Display name epSOS C-B lang.
Display name Local Terminology Repository
(based on epSOS Reference Terminology [MVC, MTC])
August 30, 2012 VLDB 2012 77
Semantic Transformation
Transcoded & Translated item Document Consumer NCP C-A Code C-A Display Name C-A Code System OID epSOS English Display Name epSOS Code System OID epSOS Code C-B Display name
August 30, 2012